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Calculating trajectories for Apollo program 
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As part of EE Times' celebration of the 40th anniversary of Apollo 11 (launched July 16, 1969) and 
the first moon landing (July 20, 1969), Jack Crenshaw describes his role in studying and creating 
trajectories for the moon missions. 


For more info on Apollo: 


Read: 

EE Time's interactive special digital edition available starting July 15th to 20th. The edition can also 
be accessed on main page of EE Times . 

Commentary: Giant Leap has lasted 40 years 

Opinion: Applying the lessons of Apollo 

Participate: 

Live webinar "Apollo: The Epic Journey that Launched a Generation of Engineers" on July 27. Have 
your say and read others' comments at Apollo forum: The epic that launched a generation of 
engineers 


All of my work on Apollo came in a frenetic four-year period, from 1959 through 1963. It was in 1959 
that I began work for the Theoretical Mechanics Division at NASA, at Langley Research Center. This 
was just shortly after NASA was formed. Shortly after I arrived there, a paper came out of the think 
tank, Rand, Inc., describing a class of lunar trajectories called free-return, circumlunar trajectories- 
-the now-familiar figure-8 paths. It was immediately obvious that this class of trajectories was the 
only reasonable way to go to the Moon and back. We began studying them intensely, using first a 
two-dimensional simulation of the restricted three-body problem, and later a 3-D, exact simulation. 

In those days, we didn't have spreadsheet programs to draw graphs for us; we had to draw them 
ourselves. As low man on the TMD totem pole, I got elected to run parametric studies on the 
computer and plot the results. That task worked in my favor, though, because I gained an 
understanding of the physics of the problem and the relationship between parameters that I don't 
think I would have gotten, otherwise. I wasn't content to just make runs and plot curves; I wanted to 
UNDERSTAND what was going on, and I think that put us ahead of the Rand guys. 














"After lifting off from the lunar surface, the lunar module made its rendezvous with the command module. The Eagle docked 
with Columbia, and the lunar samples were brought aboard. The LM was left behind in lunar orbit while the three astronauts 
returned in the command module to the blue planet in the background. (NASA photo ID AS11-44-6642)." — From Apollo 11 
mission, July 20, 1969; photo courtesy of NASA from 30th anniversary site 


I pretty much designed the parametric studies. Our group, the Lunar Trajectory Group, was small. 
Our group leader, Bill Michael, gave me the assignment, and he and I talked daily. But he never had 
to tell me, Ok, run this trajectory ... now run that one. I was the one making the day-to-day decisions. 
Bill designed the computer program but neither of us built it. In those days, things were still done 
"closed shop," and someone from the computer division wrote the code. But I did what would now be 
called desk-checking, checking the code (in IBM 702 assembler) to make sure it was right. 

Later, I did a sensitivity study, plotting the sensitivity of final to initial conditions. Nowadays, we'd 
call that a state transition matrix, but we didn't know that term, at the time. 

My boss and I published a paper in 1961, which was the second paper published on circumlunar 
trajectories. We also developed guite a number of rules of thumb, approximations, and "patched 
conic" methods that allowed us to study circumlunar trajectories without spending tons of money for 
computer time. 

Steering 

At the time, we weren't thinking of Project Apollo. In fact, I had never heard of it. We had plans to 
send a "Brownie" camera around the Moon before 1965, using NASA's solid-fuel Scout research 
vehicle. When Scout's projected payload at the Moon went from a few hundred pounds, through zero 
and negative, those plans were abandoned. However, the effort left us more than ready for Apollo 
when it came along. 

Next, I began studying the problem of steering the spacecraft, i.e., midcourse corrections. We were 
all pretty dismayed by the great sensitivity of the circumlunar trajectory to errors in initial 
conditions, and we knew the accuracy of the Scout boost guidance was orders of magnitude too low. 
Midcourse guidance would be essential. To my knowledge, my work on that topic was one of the 
earliest done, though I suspect the fellows from MIT, like Richard Battin, were studying the same 
problem. In fact, it was Battin's seminal work, seeking a midcourse correction scheme for Apollo, 




that helped make the Kalman filter practical. 


During this time, I also discovered a family of trajectories that were relatively insensitive to injection 
errors. These trajectories had a nominally vertical reentry. You see, for orbits as highly elliptical as 
translunar orbit, the perigee is almost totally a function of the angular momentum. The reguirement 
that we return with essentially the same angular momentum as the original orbit implies that the 
passage past the Moon should not alter that momentum. To achieve this result reguires very tight 
guidance. The reguired angular momentum, translated to velocity at the distance of the Moon, works 
out to be around 600 f/s. This should not be altered if we expect to achieve the kind of grazing entry 
reguired for a manned mission. Suppose, however, that we design an orbit that leaves the Moon with 
zero velocity. Then it should reenter the Earth, with a vertical entry-fatal for astronauts, but not for 
instruments. Even if our errors impart as much as 600 f/s of unplanned velocity, we will still enter 
the Earth's atmosphere and land, somewhere. If you don't care where, this peculiar class of 
trajectories allows one to fly to the Moon and back, even with the crude guidance of the old Scout. 

Of course, the mission never flew, so the trajectory is now nothing more than a footnote to space 
history. But an interesting one, nevertheless. 

In 1961 I moved to General Electric in Philadelphia, where they had landed a study contract for 
Apollo and were also planning to bid on the hardware contract. I was responsible for all the 
generation of nominal trajectories for those efforts. I did similar stuff for lunar missions that never 
flew or flew with radically altered plans; the names of projects Surveyor and Prospector come to 
mind. 

I think I did some of my very best work at GE. Generating a lunar trajectory is not easy. The problem 
is a two-point boundary-value problem, complicated by the fact that both points (the launch and 
return sites) are fixed on a rotating Earth, and we have the "minor" midpoint constraint that the 
trajectory come somewhere near the Moon. We guickly learned that simply trying to guess at 
suitable launch conditions was a hopeless venture. Therefore a large part of my energies went into 
building guite a number of patched-conic approximations, programs to solve the complicated 
spherical trig, front-end and back-end processors, and "wrappers" for GE's N-Body program. My 
crowning achievement was a fully automated program that reguired only the barest minimum of 
inputs, such as the coordinates of the launch and landing points, plus a few other things such as year 
of departure, lunar miss distance, and lighting conditions at both the Moon and Earth reentry. The 
program would then seek out the optimal, minimum-energy trajectory that would meet the 
constraints. 

I was also asked to study the problem of returning from the Moon to the Earth. Thanks to my 
experience with approximate methods, I knew exactly how to do this: Give the spacecraft a 
tangential velocity of about 600 f/s, relative to the Moon. From that desired end, it's fairly easy to 
figure out what sort of launch one needs at the Moon's surface. We generated guite a number of 
trajectories, both approximate and exact, that effected the Moon-to-Earth transfer. As far as I know, 
they were the first such studies ever done. 

During this same period, I was developing a method for computing nearly parabolic orbits. The 
classical two-body theory upon which all approximate methods are based has three distinct 
solutions, depending upon whether the orbit is elliptic, parabolic, or hyperbolic. The eguations for 
the elliptic and hyperbolic cases all go singular for an eccentricity of one. Unfortunately, that's 
exactly the kind of orbits involved in translunar missions. It drove both the computers and their 
programmers crazy, trying to solve problems so close to a singularity. I developed a set of power 
series solutions based on Herrick's "Unified Two-Body Theory." Though Herrick's original 
formulation was unsatisfactory (his functions reguired two arguments), it was a rather short step to 
replace them by new functions that used only one argument. Between 1961 and 1963,1 published 



quite a number of papers on these functions, most of them internal to GE and widely distributed 
within NASA. I was also busily putting them to work in trajectory generators. Unfortunately for me, I 
never managed to get credit for them; you'll find them today in astrodynamics texts, called the 
Lemon-Battin functions.In 1963 I spent nine months at GE's Daytona Beach facility, studying the 
problem of how to abort from the lunar mission. At first glance, you might think nothing much can 
be done; once zooming towards the moon, you're pretty much committed to continue. However, out 
near the Moon, the velocity relative to the Earth is rather low, and you have tons of available fuel for 
maneuvering, thanks to the need to enter and exit lunar orbit. Therefore, it's theoretically possible 
during some portions of the mission to simply turn around and head back for Earth. In other phases, 
you can lower the trip time quite a bit, by accelerating either towards the Moon (to hasten the 
swingby) or towards the Earth. In my studies, I discovered yet another class of returns, in which you 
make no attempt to slow down, but simply deflect the velocity downwards enough to graze the 
Earth's atmosphere. Aerodynamic braking does the rest. 

All these abort modes ended up designed into the missions and programmed into the Apollo flight 
computers. Two of them-accelerating towards the Moon on the way out, and towards the Earth on 
the way back-were used to reduce the life-critical flight time during Apollo 13. If you watch the 
movie of the same name, you'll hear discussions of Fast Return and Free Return trajectories, both of 
which I had a hand in designing. 

The computers 

Most of our work was done on the IBM 70x series, from 702 through 7094. Later in the Apollo era, 
we had Univac 1108s and 1110s, and the CDC 6600. None of them, of course, could hold a candle to 
the modern PC with Pentium processor. I think their cycles times were all around a microsecond, 
which is equivalent to a 1-MHz clock speed; not even up to the smallest microprocessor of today. 
Memory was via magnetic cores, which were even slower. The IBM's had a maximum of 32K RAM 
(but 36-bit words, not bytes). Nevertheless, the later processors, notably the Univacs and CDCs, 
were no slouch. Both had hardware floating point and long word lengths (CDC's words were 60 bits 
long), so one could do some serious number crunching. 

Despite their low performance, on paper, we got a lot of work out of those old machines. For those 
used to waiting 15 seconds for a Windows spreadsheet to even load, it's difficult to imagine how 
much work a 1-MHz computer can do when it's running full tilt in machine language, not 
encumbered by bloated software, interpreted languages, and a GUI interface. I'm old enough to 
remember, and look back on those days wistfully. 

Jack Crenshaw is a systems engineer and the author o/ Math Toolkit for Real-Time Programming . 
He holds a PhD in physics from Auburn University. E-mail him at 



